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APPARATUS AND METHOD FOR LOW FARE 
SEARCHING. IN A COMPUTER NETWORK 
Related Application 

This application claims the benefit of U. S. Provisional Application No. 
5 60/097,829, filed August 31, 1998, the disclosure of which is expressly incorporated 
herein by reference in its entirety. 
Technical Field 

The present invention relates to the field of computerized reservation systems 
such as airline reservation systems used by airline ticket agents and travel agents. 
10 More particularly, the invention relates to a system and method for performing a low 
fare search in a computer-based network. 
Background Art 

A computerized reservation system (CRS) provides a communications 
network for travel agents and other users to book airline reservations. Travel-related 

1 5 businesses and other companies may interface their computer systems with a CRS in 
order to make information concerning their services available via the CRS. For 
example, a hotel company may interface its reservation system with a CRS so that 
when a person books an airline reservation, he or she may also make a hotel 
reservation through the same network. 

20 The major computerized reservation systems currently in use throughout the 

world share a common heritage. They also have common business assumptions that 
were true nearly two decades ago. Examples of such reservation systems are known 
or referred to under the following trade names and service marks: SABRE; 
AMADEUS; WORLDSPAN; SYSTEM ONE; APOLLO; GEMINI; GALILEO; and 

25 AXESS. Under these systems, a customer chooses an itinerary, based on their 

desired travel dates and times, and books the itinerary through the CRS. A pricing 
system then computes a price for this itinerary. Pricing systems typically allow a 
user to vary their selection based on the class of service, thus enabling a user to 
select the cheapest fare for a fixed itinerary. This was ideal prior to airline 

30 deregulation and still works well for certain business travelers. 



WO 00/13124 PCT/US99/19837 

-2- 

The conventional systems, however, suffer from a number of limitations and 
drawbacks that are related to a number of factors. These factors include the increase 
in the number of options available to travelers, the daily changes in flight fares, and 
the various restrictions that may apply to certain fares. For example, thousands of 
5 separate fare changes are made and published every day for flights in the United 

States. Only some of those fares are reflected in the existing CRS's. Often, when a 
travel agent or user requests the lowest fare itinerary , many of the returned fares are 
accompanied by a message that indicates that the fare shown on the screen is subject 
to restrictions or changes that are not checked automatically. The travel agent or 

1 0 user must then decide whether or not the fare is valid based on certain rules. If the 
fare is not valid, the travel agent or user must display the fares and the rules for each 
fare, or look at the most recent rulebook available at the time and hope that the 
information there still holds. In certain cases, the travel agent may need to telephone 
the particular airline or airlines to check each fare. This problem is compounded 

1 5 when the travel agent or user seeks to investigate the trade-offs between several 
different itineraries. For example, the trade-offs between the cost of the travel in 
terms of ticket price, travel time, and convenience. This makes it difficult to find the 
best value for a particular itinerary, while at the same time increasing the time it 
takes to arrange a particular trip. 

20 Accordingly, there is presently a need exists for a system or process for 

efficiently finding the lowest fare through a network environment. There is also a 
need for an automated system or process for identifying and arranging an itinerary 
for any given traveler's needs. 

Disclosure of the Invention 

25 A method consistent with the present invention provides for low price 

searching. In this method search request data identifying a particular item is 
received at a processor. Availability information reflecting availability of a set of 
items in an inventory is then obtained, each item in the set corresponding to the 
particular item. After obtaining the information, it is ascertained whether the search 

30 request data includes a target price reflecting a user's price preference associated 
with the item. A determination is then made as to whether price information 
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associated with each item in the set substantially satisfies the target price. After 
which, a selection of an item from the set is confirmed based on the determination. 

An apparatus consistent with the present invention performs low price 
searching. The apparatus receives search request data identifying a particular item. 
5 Availability information reflecting availability of a set of items in an inventory is 
then obtained, each item in the set corresponding to the particular item. After 
obtaining the information, it is ascertained whether the search request data includes a 
target price reflecting a user's price preference associated with the item. A 
determination is then made as to whether price information associated with each 
1 0 item in the set substantially satisfies the target price. After which, a selection of an 
item from the set is confirmed based on the determination. 

Brief Description of The Drawings 
The accompanying drawings are incorporated in and constitute a part of this 
specification and, together with the description, explain the advantages and 
15 principles of the invention. In the drawings, 

FIG. 1 is a diagram of an exemplary computer network environment in which 
the features and aspects of the present invention may be implemented; 

FIG. 2 is a diagram of an exemplary computer network in which the broker 
of the present invention may be implemented; 
20 FIG. 3 is an exemplary flow chart consistent with the low fare search method 

of the present invention; 

FIG. 4 is an exemplary flow chart of a process for selecting the type of low 
fare search, in accordance with an aspect of the invention; 

FIG. 5 is an exemplary flow chart consistent with the shopper/looker 
25 processing of the present invention; and 

FIG. 6 is an exemplary flow chart consistent with the booker processing of 
the present invention. 

Detailed Description 
The following detailed description of the invention refers to the 
30 accompanying drawings. While the description includes exemplary embodiments, 
other embodiments are possible, and changes may be made to the embodiments 
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described without departing from the spirit and scope of the invention. The 
following detailed description does not limit the invention. Instead, the scope of the 
invention is defined by the appended claims and their equivalents. 

The search technique of the present invention provides for efficient searches 
5 for low fares in a computer network. Search request data is sent from a client system 
to a broker. If the search request data includes a target price, then the broker 
performs a booking operation. The booking operation books a reservation for a 
customer if search response data received by the broker from a host system is not 
greater than the target price. This target price is supplied by the customer. If the 

1 0 search request data does not include a target price, then the broker performs a 

shopper operation. The shopper operation returns an output message with low fare 
information to the client system without booking a reservation. 

FIG. 1 is a diagram of a network environment 100 including one or more 
CRS's. CRS's are networks permitting access to, for example, travel-related 

15 information for making reservations or obtaining such information. CRS's may use 
and provide other types of information, depending upon the computer systems 
interfaced with a particular CRS or the information accessible by the CRS. CRS's 
are commonly referred to as computer reservation systems or central reservation 
systems. In European countries, for example, CRS's are often referred to as global 

20 distribution systems. The term "computerized reservation system" and the 

abbreviation "CRS" are intended to encompass computerized reservation systems, 
computer reservation systems, central reservation systems, and global distribution 
systems. Examples of CRS's include those known by the following trade names and 
service marks: SABRE; AMADEUS; WORLDSPAN; SYSTEM ONE; APOLLO; 

25 GEMINI; GALILEO; and AXESS. 

Network environment 100 illustrates an architecture for customers or service 
providers to link together through computerized reservation systems, such as CRS 
1 12 or 126. For example, customer machines 101 and 102 may represent machines 
located at a particular business or other entity for providing travel-related and other 

30 services for that business or entity. Customer machines 101 and 102 are typically 
interfaced through a frame relay 103 and a router 104 to a server machine 105. 
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Router 104 provides for routing of a protocol over frame relay 103 for long distance 
communication. Server machine 105 provides necessary interaction between the 
ultimate customer machines and a CRS, for example, CRS 126. 

Server machine 105 is typically interfaced through a universal data router 
5 (UDR) 1 06 to a network 1 10. UDR 106 may include several servers, as explained 
below, for performing data conversion for server 105 to communicate with a CRS, 
for example, CRS 126. Network 1 10 may represent a telephony network such as the 
Societe Internationale Telecommunications Aeronautiques (SIT A) network. 
Network 1 10 interfaces UDR 106 with a front end processor 111, which provides an 

10 interface to a CRS 1 12. A CRS usually includes a front end processor, which are 

known mainframe components, providing functionality for interfacing the CRS with 
a network. Customer machines 101 and 102 may also be interfaced with other 
CRS's through UDR 106. Therefore, when a person at customer machine 101 or 102 
desires to, for example, book a travel-related reservation or access other types of 

1 5 information, a communications link is established through the various elements 
between the customer machine and CRS 1 12 or 126. CRS 112 may also be 
connected to a client system 1 1 7 through a broker 1 i 6. These units are explained in 
more detail in conjunction with FIG. 2. 

In addition, network 110 may interface travel agent machines 1 14 and 115 

20 with CRS 1 12 or 126. In particular, network 1 10 may interface a local area network 
(LAN) 1 13 connected to travel agent machines 1 14 and 1 1 5. Travel agent machines 
1 1 4 and 1 1 5, if located overseas, may also be linked into CRS 1 12 or 1 26. In such a 
case, network 110 may interface token ring LAN 1 13 through an international 
telephone or computer network (not shown). 

25 Other companies or service providers may also provide information available 

via CRS 1 12. Such information may be provided, for example, by interfacing 
service provider machines or other computer systems 124 and 125 through UDR 120 
to front end processor 111. UDR 120, which may include several servers, provides 
data conversion to interface the service provider machines 124 and 125 in 

30 accordance with the protocol used by CRS 1 12. Alternatively, service provide 
machines 124 and 125 may interface with UDR 106 and/or CRS 126. 
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FIG. 2 is a diagram of a computer network 200 in which the present 
invention may be implemented. Host 201 can be configured as a CRS similar to 
those described above with reference to FIG. 1. For example, host 201 can be 
implemented by any of a number of different types of CRS's including a SABRE 
5 Host, or any of the other aforementioned CRS types. Host 201 is connected to 

broker 202 through a link that is preferably compliant with a known protocol, such 
as the TCP/IP protocol. Broker 202 can be implemented using a server machine 
equipped with a Pentium II processor from Intel Corporation, RAM, hard drives, and 
a network card such as the Ethernet 10/100 LAN card. Broker 202 also includes 
10 operating system and software, including at least Microsoft NT Server Version 4.0, 
Microsoft Service Pack Version 3.0, and DATABAHN™ Version 1 .0. The broker 
202 is capable of sending requests to the Host 20 1 in multiple sessions that can be 
substantially simultaneous. Sending multiple requests in substantially simultaneous 
sessions is known in the art. As further described below, broker 202 can be 
5 implemented with the low fare search function and other features and aspects of the 
present invention. 

Broker 202 is connected to client System 203 through a link that is preferably " 
. compliant with a known protocol, such as the TCP/IP protocol. Client system 203 is 
a system for entering low fare search request data to be used by broker 202 to 

perform a low fare search. One example of a possible client system is the Gallery 
System available from Cendant. Client system 203 is also connected to a database 
205 for shipping products and a membership system 204, Users 208, 209, 210 can 
access client system 203 through session management tool 206 or through the 
Internet 207. Session management tool 206 is a known tool that manages the access 
of multiple users to a central system via time-sharing. Users 208, 209, 210 can be 
customers, travel agents, and the like. 

FIG. 3 is an exemplary flowchart of the processes and operation that occur 
between client system 203, broker 202, and host 201, in accordance with various 
aspects of the invention. A customer enters travel plan data using a graphical user 
interface, web-based mask, or other user interface. The travel plan data may 
comprise basic flight request data (e.g., origin / destination city pair codes, 
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departure/return date and time, preferred carrier codes, etc.) and other travel data. 
The customer sends this data to client system 203, where the travel plan data is 
converted into low fare search request data. The client system 203 sends the low fare 
search request data to the broker 202 (step 305). An example of the manner and 
5 format by which client system 203 sends the data to broker 202 is described below. 

The broker 202 initializes various tables and variables that will be needed, 
receives the request data, parses and verifies the data, and checks for errors (step 
3 1 0). If the broker 202 determines that the received data is not valid (step 3 1 5), then 
an appropriate error message is sent to the client system (step 320). An example of 

1 0 request data that is considered invalid occurs when a customer enters an invalid 
number of passengers or an invalid class of service. After being notified that the 
request data is invalid (step 3 1 5), the customer must re-enter the data (step 320), so 
that the corrected request data can be sent to the broker 202. 

If the broker 202 determines that the received data is valid (step 3 1 5), then 

1 5 the broker builds low fare search requests in a format that is appropriate for the 

particular type of host 201 that is being utilized (step 330). Multiple search requests 
are built because the search technique of the present invention requires that the 
lowest fare be found in several different respects (i.e. lowest available fare, lowest 
published fare). In this manner, the customer will be provided with more data to 

20 allow for an informed decision. The broker 202 builds these requests using known 
methods. The search requests could be, for example, built using the functionality of 
the DATABAHN™ application or similar applications. In general, DATABAHN™ 
is an application in which there is a translation from search request data in an input 
data format (i.e., SDS) to a format that is understood by a CRS. Translation from 

25 the CRS format to an output data format (i.e., SDS) also occurs. After creating and 
initializing multiple sessions with the host 201, and opening a connection to the host, 
the broker 202 sends the low fare search requests to the host 201 (step 335). 
Generally, one session is associated with one request. So, if there are three requests, 
then there would be three sessions. After receiving the search requests, the host 201 

30 processes the requests and returns the relevant search data (step 340). The broker 
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202 then verifies the search data (step 345), extracts the relevant lowest fare search 
data and stores lowest fare search data in a table for processing (step 350). 

After storing the data, the broker 202 sorts or filters the lowest fare search 
data (step 355). For example, broker 202 might sort the data from lowest to highest 
5 total fare price. The broker 202 then constructs an output message (step 360) and 
sends the output message to the client 203 along with any other responses received 
from the host 201 in a multi-message format. The functionality of the 
DATAB AHN™ application or similar applications can be used to send the responses 
in the appropriate format. 

10 FIG. 4 is an exemplary flowchart depicting various operations and processes 

performed by broker 202 in accordance with the features of the present invention. 
Broker 202 receives request data from the client system 203 in accordance with the 
process depicted in FIG. 3 (step 405). When entering data into the client system 203 
to send to the broker 202, the customer may have the option of designating either an 

1 5 information only request or a tentative booking request. Generally, a customer 

makes the choice by either specifying a target price or not specifying a target price. 
If a target price is set, then a tentative booking request is made. If a target price has 
not been set, then an information only request has been made. If an information only 
request has been chosen by the customer (step 410), then the broker 202 starts to 

20 perform a shopping operation (step 415). The shopping operation might be 

preferable to a customer who is not certain of their travel plans or does not wish to 
make reservations, but merely wants to see the going rates and/or to estimate travel 
expenses. If, on the other hand, a tentative booking request is sent to the broker 202 
(step 410), then the broker will proceed to perform a booking operation (step 420). 

25 It is called a tentative booking request because even after a booking has been made, 
there needs to be a confirmation of the booking at a later time, perhaps with some 
form of payment. cOnce confirmation has been received, a booking can become 
permanent. 

FIG. 5 is an exemplary flowchart depicting the various processes and 
30 operations of the shopper operation of the present invention. After it has been 

determined that there is an information only request, the broker 202 examines the 
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low fare search request data (step 505). As part of the request data from the client 
system 203, broker 202 may receive the following data so that it can properly 
generate a response: departure date; departure time; return date; return time; 
departure city; return city; direct/non-stop indicator; number of passengers; class of 
5 service; carrier code client; carrier code customer; passenger type. Of the above 
listed data, departure date, departure city, and return city are data that may be 
minimally required for processing of the request to be properly completed. The 
other data may be optional. This request data may be sent to the broker 202 in a 
particular format, such as the Sabre Data Stream (SDS) format 

10 Once the request data has been examined, a determination is made as to 

whether or not the customer specified a preferred carrier (step 5 1 0). If the customer 
did not specify a carrier (step 510), then the broker 202 builds a search request to 
find the lowest available fare without identifying a preferred carrier and sends the 
request to the host 201 (step 515). The host 201 processes the request and returns 

1 5 the search data back to the broker 202 in accordance with the features of FIG. 3 . 

The broker 202 can also build a search request to find the lowest available 
fare using the client's preferred carriers (step 520). For example, the client that is 
providing the client system 203 might have a pre-arranged deal with several airlines. 
The client would probably prefer the customer to use the airline with which business 

20 is usually done. This request is also sent to the host 201 , where it is processed (step 
520). The broker then builds a search request to find the lowest published fare and 
sends the request to the host 201 (step 525). Generally, the lowest published fare is 
determined by the broker 202 by first identifying the lowest fare in the data received 
from the host 201 that is validated against the service available. For example, if a 

25 low fare is displayed, but the header information indicates that the carrier has no 
service in the market, the fare would be eliminated. The elimination of fares 
decreases the amount of time spent trying to find the lowest fare. Next, based on 
biasing the system for the client's preferred carriers, the lowest fare is identified and 
determined for the travel dates and city pairs specified in the request data. Once 

30 identified, the travel restrictions (i.e., rules) for the lowest fare will be cached for 
messaging back to the client system. In that manner, the lowest published fare is 
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found. It should be understood that although FIG. 5 shows the various search 
requests being processed in a sequential manner, at least some of these requests can 
be processed and sent to the Host 201 substantially simultaneously utilizing multiple 
sessions. 

5 After receiving all of the requested search data from the host 201 , the broker 

202 processes the data in accordance with the features of FIG. 3 and then sends an 
output message back to the client 203 (step 530). The message may include the 
lowest available fare that was found when using no carrier designation, the lowest 
available fare that was found when using the client's preferred carriers, and the 

1 0 lowest published fare that was found. Along with each of the fares, the 

corresponding rules for each fare are sent. Rules are carrier defined conditions that 
go along with a particular fare. For example, a fare might only be valid if made two 
weeks in advance of the departure date. The message sent to the client 203 from the 
broker 202 is generally known as a message definition record (MDR) and is 

15 preferably sent using the SDS format, which is further explained below. 

If the customer has specified a preferred carrier (step 510), then processing is 
different. The broker 202 builds a search request to find the lowest available fare 
without identifying a preferred carrier and sends this request to the host 201 (step 
535). Then, the broker 202 builds a search request to find the lowest available fare 

20 using the client's preferred carriers and sends that request to host 201 also (step 

540): During these steps, the host 201 is still operating normally (i.e., processing the 
requests and returning search data). Once the broker 202 has received both sets of 
search data from the host 201, the broker compares the lowest fare using no carrier 
with the lowest fare using the client's carriers and selects the lowest of the fares 

25 (step 545). The client can specify multiple carriers, so this comparison can be 

between more than two fares. The broker 202 then builds a search request to find 
the lowest available fare using the customer's preferred carriers and sends the 
request to the host 201 (step 550). The last request to get built and sent to the host 
201 is to find the lowest published fare (step 555). After receiving all of the 

30 requested search data from the host 201 , the broker 202 processes the data in 

accordance with the features of FIG. 3, and then sends an output message back to the 
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client 203 (step 560). The message may include the lowest available fare that was 
found when using the customer's preferred carriers, the lowest of the fares from the 
comparison between the fare with no carrier and the fares of the client's carriers, and 
the lowest published fare that was found. Along with each of the fares, the 
corresponding rules for each fare are sent. The message sent to the client 203 from 
the broker 202 is sent using the SDS format. It should be understood that although 
FIG. 5 shows the various search requests being processed in a sequential manner, at 
least some of these requests can be processed and sent to the Host 201 substantially 
simultaneously utilizing multiple sessions. 

FIG. 6 is an exemplary flowchart of the various processes and operations for 
performing the booking operation, in accordance with the present invention. After it 
has been determined that there is a tentative booking request, the broker 202 
examines the low fare search request data (step 605). As part of the request data 
from the client system 203, the broker 202 may receive one or more of the following 
data so that it can properly generate a response: departure date; departure time; 
return date; return time; departure city; return city; direct/non-stop indicator; number 
of passengers; class of service; carrier code client; carrier code customer; adjustment 
for departure; adjustment for return; passenger type; member source; member 
number; e-mail address; target price; passenger last name; passenger first name; 
mailing address; city; state; zip code; home phone; work phone; market code; agent 
sine; ticketing time limit; and customer number. Of the above listed data, departure 
time, return date, return time, direct/non-stop indicator, carrier code customer, 
adjustment for departure, adjustment for return, passenger type, and e-mail address 
may be optional data and all other data may be mandatory. The adjustments for 
departure and return are of particular interest. This data allows the customer to 
indicate that he or she is flexible with respect to when he or she departs or returns. 
The broker 202 performs searches for low fare data with respect to this flexibility, 
thereby giving the customer a better chance of finding a fare that meets the target 
price. Member source and member number are for users that belong to certain 
organizations that might make them eligible for special rates. Market code is an 
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identification of the pertinent market being dealt with. Agent sine is an 
identification of an agent that may be using the system. 

Once the request data has been examined, a determination is made as to 
whether or not the customer specified a preferred carrier (step 610). If the customer 
5 did not specify a carrier (step 610), then the broker 202 builds a search request to 
find the lowest available fare without identifying a preferred carrier and sends this 
request to the host 201 (step 615). Then, the broker 202 builds a search request to 
find the lowest available fare using the client's preferred carriers and sends that 
request to host 201 (step 620). Once the broker 202 has received both sets of search 

1 0 data from the host 201 , the broker compares the lowest fare using no carrier with the 
lowest fare using the client's carriers and selects the lowest of the fares (step 625). 
If the lowest fare from the comparison is not greater than the target price specified 
by the customer (step 635), then the broker 202 builds a passenger name record 
(PNR) and sends it to the client 203. Building a passenger name record is an 

1 5 indication that a tentative booking has occurred. 

If the lowest fare from the comparison is greater than the target price (step 
635); then the broker builds a search request to find the lowest published fare and 
sends the request to the host 201 (step 640). After receiving all of the requested 
search data from the host 201, the broker 202 processes the data in accordance with 

20 the features of FIG. 3, and then sends an output message back to the client 203 

(step 645). The message may include the lowest available fare that was found when 
using no carrier designation, the lowest available fare that was found when using the 
client's preferred carriers, and the lowest published fare that was found. Along with 
each of the fares, the corresponding rules for each fare may be sent. It should be 

25 understood that although FIG. 6 shows the various search requests being processed 
in a sequential manner, at least some of these requests can be processed and sent to 
the Host 201 substantially simultaneously utilizing multiple sessions. 

If the customer did specify a preferred carrier (step 610), then processing 
proceeds in a different manner. First, the broker 202 builds a search request to find 

30 the lowest available fare using the customer's preferred carriers and sends the 

request to the host 201 (step 650). After, the broker 202 has received the search data 
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from the host 201, the lowest available fare is compared to the target price 

(step 655). If the lowest fare is not greater than the target price (step 655), then the 

broker 202 builds a PNR and sends it to the client 203 (step 660). 

If the lowest fare is greater than the target price (step 655), then the broker 
5 202 builds a search request to find the lowest available fare without identifying a 
preferred carrier and sends this request to the host 201 (step 665). Then, the broker 
202 builds a search request to find the lowest available fare using the client's 
preferred carriers and sends that request to host (step 670). Once the broker 202 has 
received both sets of search data from the host 201, the broker compares the lowest 

10 fare using no carrier with the lowest fare using the client's carriers and selects the 

lowest of the fares (step 675). The last request to get built and sent to the host 201 is 
to find the lowest published fare (step 680). After receiving all of the requested 
search data from the host 201, the broker 202 processes the data in accordance with 
the features of FIG. 3 and then sends an output message back to the client 203 

1 5 (step 685). The message may include the lowest available fare that was found when 
using the customer's preferred carriers, the lowest of the fares from the comparison 
between the fare with no carrier arid the fares of the client's carriers, and the lowest 
published fare that was found. Along with each of the fares, the corresponding rules 
for each fare may be sent. The message sent to the client 203 from the broker 202 is 

20 preferably sent using the SDS format. It should be understood that although FIG. 6 
shows the various search requests being processed in a sequential manner, at least 
some of these requests can be processed and sent to the-Host 201 substantially 
simultaneously utilizing multiple sessions. 

The processing of the broker 202 described above is not limited to the 

25 specific methods disclosed above. For example, in addition to finding the lowest 
available fare and the lowest published fare, the broker 202 can identify the lowest 
applicable fare based on the specified travel dates and city pairs, and send this 
information back to the client system. The lowest applicable fare is generally the 
lowest fare that meets the customer's needs that is not necessarily bookable (i.e., 

30 available) at the time. This information is useful to the customer because a lowest 
applicable fare could be lower than a lowest available fare. If that is the case, then a 
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customer might want to wait until the lower fare became available before actually 
making travel arrangements. 

While the present invention has been described in connection with a 
preferred embodiment, many modifications will be readily apparent to those skilled 
in the art, and this application is intended to cover any adaptations or variations 
thereof. This invention should be limited only by the claims and equivalents thereof. 
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WHAT IS CLAIMED IS: 

1. A method for low price searching comprising the steps, performed by a 
processor, of : 

a) receiving search request data identifying a particular item; 
5 b) obtaining availability information reflecting availability of a set of items 

in an inventory, each item in the set corresponding to the particular item; 

c) ascertaining whether the search request data includes a target price 
reflecting a user's price preference associated with the item; 

d) determining whether price information associated with each item in the 
1 0 set substantially satisfies the target price; and 

e) confirming a selection of an item from the set based on the determination. 

2. The method of claim 1 , further comprising: 

bypassing steps c) through e) based on a determination that the search request 
data does not include a target price. 
1 5 3. The method of claim 1 , wherein said particular item is a travel itinerary. 

4. The method of claim 1, wherein the search request data indicates 
flexibility in departure _and/or return date. _ ; _. . ..... . 

5. The method of claim 1 , wherein the search request data is entered by a 
customer on a user interface. 

20 6. The method of claim 5, wherein the user interface is web-based. 

7. The method of claim 1 , wherein the search request data includes a 
customer's preferred carriers and/or a client's preferred carriers. 

8. The method of claim 1 , wherein the obtaining step further comprises: 
building search requests based on said search request data; and 

25 - sending search requests to a host system, wherein the availability information 

is received from the host system in response to the search requests. 

9. The method of claim 8, wherein said search requests are sent to the host 
system in multiple sessions that occur substantially simultaneously. 

1 0. The method of claim 1 , wherein the confirming step further comprises: 
30 booking a reservation if the price information is not greater than the target 

price. 
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1 1 . The method of claim 1 0, wherein the booking step comprises building a 
passenger name record (PNR). 

12. An apparatus for low price searching comprising: 

means for receiving search request data identifying a particular item; 
5 means for obtaining availability information reflecting availability of a set of 

items in an inventory, each item in the set corresponding to the particular item; 

means for ascertaining whether the search request data includes a target price 
reflecting a user's price preference associated with the item; 

means for determining whether price information associated with each item 
in the set substantially satisfies the target price; and 

means for confirming a selection of an item from the set based on the 
determination. 

13. The apparatus of claim 12, wherein said particular item is a travel 
itinerary. 

14. The apparatus of claim 12, wherein the search request data indicates 
flexibility in departure and/or return date. 

15. The apparatus of claim 12, wherein the search request data is entered by 
a customer on a user interface. 

1 6. The apparatus of claim 1 5, wherein the user interface is web-based. 

17. The apparatus of claim 12, wherein the search request data includes a 
customer's preferred carriers and/or a client's preferred carriers. 

1 8. The apparatus of claim 12, wherein the means for obtaining further 
comprises: 

means for building search requests based on said search request data; and 
means for sending search requests to a host system, wherein the availability 
information is received from the host system in response to the search requests. 

1 9. The apparatus of claim 1 8, wherein said search requests are sent to the 
host system in multiple sessions that occur substantially simultaneously. 

20. The apparatus of claim 12, wherein the means for confirming further 
comprises: 

means for booking a reservation if the price information is not greater than 
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the target price. 

21 . The apparatus of claim 20, wherein the means for booking builds a 
passenger name record (PNR). 1 
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